2024/2 更新 - 實體書平裝版本上市

在經過快要一年的努力後，本系列文的實體書版本推出了～其中新增並補充了許多鐵人賽版本中沒有的脈絡與細節，並以全彩印刷拉滿視覺上的閱讀體驗，現正熱銷中！有興趣的話歡迎參考看看，也歡迎分享給其他有接觸前端的朋友們，非常感謝大家～

《React 思維進化：一次打破常見的觀念誤解，躍升專業前端開發者》

首刷的軟精裝版本各大通路都已經銷售一空，接下來會再刷推出新的平裝版本：

天瓏（平裝版）：
https://www.tenlong.com.tw/products/9786263337695

博客來（平裝版）：
https://www.books.com.tw/products/0010982322

momo（平裝版）：
https://www.momoshop.com.tw/goods/GoodsDetail.jsp?i_code=12528845

終於，在無數個趕稿的夜晚後，我們終於走到了鐵人賽的最後一篇。在這一系列的文章中，我們深入解析了許多 React 的重要觀念與背後的設計脈絡，在系列文的最後一篇中也在這邊做個盤點以及總結回顧，並且來談一談我自己參加這次鐵人賽的緣由以及感言。

系列文總結

這個系列文的文章主題大致可以分為幾個部分：

React 畫面管理機制的核心觀念

• [Day 04] DOM 與 Virtual DOM
• [Day 05] 建構一切 UI 的最基本單位 — React element
• [Day 06] Render React elements
• [Day 07] JSX 根本就不是在 JavaScript 中寫 HTML
• [Day 08] JSX 的重要特性與規則以及其背後緣由
• [Day 09] 單向資料流 & DOM 渲染策略
• [Day 10] React 畫面更新的核心機制（上）：一律重繪渲染策略
• [Day 11] React 畫面更新的核心機制（下）：Reconciliation

一套前端框架或解決方案中，畫面管理永遠是最核心的根本問題。在筆者我擔任前端面試官的這幾年以來，當我提出問題「請幫我們分享並解釋一下，在 React 中從呼叫 setState 到最後看到畫面真的發生改變，中間的流程發生了哪些事情？」，有許多人只能講出一些片面的關鍵字，但是對於其運作的原理與觀念幾乎是一知半解的狀態。

我曾經就面試過一位 candidate 以「Virtual DOM」以及「新舊比較」這兩個關鍵字，掰出一段講的很流暢但完完全全錯誤的 reconcilication 流程，真的是讓我當場愣住...

然而畫面的產生與管理機制可以說是 React 核心機制，多數的其它配套機制的設計也基本上是服務於這個最重要的需求。這是以 React 作為專業技術使用的開發者們都應該要熟悉掌握的基本功。

setSate & immutable update

• [Day 12] 如何在子 component 裡觸發更新父 component 的資料
• [Day 13] 深入理解 batch update
• [Day 14] 以 functional updater 來呼叫 setState
• [Day 15] 維持 React 資料流可靠性的核心關鍵：Immutable state
• [Day 16] Immutable update 物件與陣列的基本功
• [Day 17] Immutable update 的 nested reference clone 誤解

另一個 React 新手（甚至有些工作經驗兩三年的人也是）最常犯的錯誤就是 immutable state 的 update。前一陣子為了任職公司的招募需求，我替我們前端團隊的徵才流程設計了一個作業的環節，其中就有出現陣列包著物件這種形式的 state，然而其中有非常多人直接以 spread 頂層陣列後直接 mutate 裡面內容的方式來寫：

const [cartItems, setCartItems] = useState([])

const handleIncrementQuantity = (index) => {
  // ❌ 注意，這樣寫是有問題的
  const newCartItems = [...cartItems];
  newCartItems[index].quantity += 1;
  setCartItems(newCartItems);
}

而另外一部份的人則是雖然正確的操作了 immutable update，但是當我請他們分享這麼做的原因時，幾乎回答都是「習慣這樣寫」、「沒有特別的原因」。如果 reconciliation 是 React 中畫面管理機制的基本功，那 immutable state 及其 update 就是資料流觀念與操作的基本功，攸關 React 核心機制的運作正確與否，務必要確實的掌握。

Component render 的資料流與 useEffect

• [Day 18] Function component & class component 你可能不知道的關鍵區別
• [Day 19] 每一次 render 都有自己的 props、state 以及 event handlers
• [Day 20] 每一次 render 都有自己的 effects
• [Day 21] useEffect 其實不是 function component 的生命週期 API
• [Day 22] 保持資料流 — 不要欺騙 hooks 的 dependencies（上）
• [Day 23] 保持資料流 — 不要欺騙 hooks 的 dependencies（下）
• [Day 24] useEffect dependencies 的經典錯誤用法
• [Day 25] Reusable state — React 18 的 useEffect 在 mount 時為何會執行兩次？
• [Day 26] Effects & cleanups 常見情境的設計技巧

useEffect 可能是 React 所有的 API 中被最常被人誤解的一個了，大多數過去有 class component 開發經驗的人幾乎都會嘗試以生命週期 API 的角度去理解和使用它。然而 function component 其實沒有提供生命週期的 API，只有 useEffect 用於「從資料同步到 effect 的行為與影響」。我們應該嘗試以 render 的資料流的角度去理解 effect，相信這些篇章中的詳細解析能幫助到你。

其它 Hooks 相關

• [Day 27] useCallback 與 useMemo 的正確使用時機
• [Day 28] 一次弄懂 React hooks 的運作原理與設計思維（上）
• [Day 29] 一次弄懂 React hooks 的運作原理與設計思維（下）

最後則就是補充一些其它常用 hooks 的解析，以及深入分析 hooks 本身的運作原理以及背後的設計思維，幫助破除大家對於覺得 hooks 像是「黑魔法」的認知。

完賽感言

這麽多年來接觸並投入 React 這項技術的經驗，讓我深知學習 React 的不容易。React 一直以來的發展發向都是專注於引領前端技術的思想革新，無論是 Virtual DOM 配合一律重繪渲染策略的實踐，或是 function-base 的 hooks 設計，都對整個前端技術以及社群的演進帶來巨大的影響力。

然而 React 的設計一直以來都傾向盡量減少「黑魔法」，盡量以純粹、透明為原則，而非傾向於防呆、低門檻、高容錯率。因此對於開發者來說，React 學習起來會比其他前端框架更依賴於「思想模型認知」，當你對這些核心觀念以及設計脈絡一知半解時，你很難理解到程式碼為什麼要這樣寫，覺得 React 的許多設計與行為都很不直覺甚至莫名其妙。然而，這些觀念、思想類的累績並不會因為你一直不斷的重複實作專案就突然自己悟透。在沒有扎實的基本功的前提下，就算是帳面上的十年的開發經驗也可能只是一年的皮毛經驗連續重複十次，對於技術能力突破的幫助其實非常有限。

這並不是代表實作練習不重要，而是你必須要在掌握正確核心觀念的前提下，帶著這些東西有意識的去投入實作累積，才會產生內化到思維中的進步成效，兩者缺一不可。就像我上面提到的，我實在面試過太多寫了 React 幾年的開發者，卻連 React 是怎麼更新畫面的都不知道。這就好比一位外科手術醫生，即使手操的刀法再怎麼精湛、熟練，但是如果他沒有扎實的理論知識，知道往哪裡切下去會造什麼影響、如果大量出血時該怎麼應對…等等，那麼你會敢讓這位醫生為你開刀嗎？

忽略基本功的重要性而憑感覺依樣畫葫蘆，確實是相對簡單輕鬆的。如果你對於這個領域的學習只是興趣導向，那抱持著嘗試看看的想法是完全沒有問題的；然而如果你把這項技術當作專業能力投入在工作上的話，這可能就不是那麼理想的專業態度的展現。你得先尊重自己是一位擁有專業知識與技術的工程師，而不是只個懂皮毛的流水線作業員，則你的工作夥伴乃至於這個業界，也才會尊重你的專業能力以及態度。

我自己在學生時所受過的資訊教育讓我深知這個部分的重要性，因此在學習 React 相關技術的這條路上，我下了非常多的功夫去扎實的理解、參透這些觀念以及背後的設計思維，才能夠漸漸累積並突破到現在的技術能力。而這幾年工作的經驗中也看到了許多剛接觸 React，或甚至已經寫了幾年 React 的工程師，都仍然在這個門檻上苦苦掙扎。在這一兩年的趨勢中，有越來越多的朋友無論是透過一些教育機構、或是自學的努力，投入到前端這個領域來。有更多的新血加入這個業界本身是一件好事，但是其中有非常大比例的朋友們仍尚未意識到扎實的基本功對於工程師職涯的重要性，又或是已經意識到了，卻苦於沒有較為系統性的學習資源而突破得很辛苦。

這其實也就是我這次會想要參加鐵人賽的一個重要原因。坊間的許多課程為了在有限的時間內盡量以讓學員找到第一份工作為優先目標，因此課綱大多都會比較偏重工具使用與實作練習，而較少重視核心觀念的基本功穩固。如果考量到課程的商業層面以及影響力的效益，其實這種做法多少也是可以理解。然而對於軟體工程師來說，基本功的知識和觀念不扎實，其實會嚴重的影響實務能力的可靠性以及各種情境的應變能力，即戰力因而大打折扣。不過其中也有許多真的對這個領域充滿熱情、學習動機強的新人工程師們，其實他們需要的只是適合的學習資源。因此我希望透過系列文這種形式，能夠更有系統性的來解析這些基本功的觀念，希望能對於正在學習 React 或是已經有 React 的經驗但是苦惱於難以進一步掌握的朋友們有所幫助。

除此之外，參加鐵人賽分享自己的技術理解，對我來說也是一種社群的回饋。我自己在學生時期時就積極的參與各式各樣的技術社群，受到過許多社群前輩們的幫助，從他們身上學習到的許多東西無論是技術，或是身為工程師的專業態度，都對我的職涯影響重大。其中尤其想特別在這裡感謝 JavaScript 社群的 Caesar，以及 Laravel 社群的聖佑，他們在我還是學生的那些年中給了我非常多的幫助以及各種突破自我的學習機會，也讓我了解到在社群中樂於交流分享的意義與重要性。這促使我在如今自己也成長茁壯後有能力幫助其他人時，想要去出一份力回饋於這個社群，也才有了這次鐵人賽的參賽。

當然參加鐵人賽終究也是對自我的一種挑戰，無論是技術層面、表達能力層面，又或是心理層面。在工作上成長到 senior 之後，你要做到的就不僅僅是自己熟悉這些技術，而是有能力去外溢能量給你的其他夥伴身上。然而「自己懂」，與「教到別人也能懂」，相信大家都知道完全是兩回事。對於交流分享以及 mentorship 的熱情，讓我投入的許多心力在提升自己這方面的能力，參加鐵人賽去連續三十天都撰寫每篇都數千字的扎實技術觀念文章，絕對是一個 push 自己有所突破與成長的機會。

然而地獄般的賽程確實是一個重大的挑戰，而我也不想只是為了完賽而產出自己無法滿意的文章，因此在後半段的賽程中確實是每天都衝刺到半夜 11 、12 點才完稿，同時還要兼顧職場的工作。而最讓我一度覺得難受的，還是在賽程中遇到了家人因為身體有恙而住院的情況。在同時面對陪病照護、工作、鐵人賽的三重壓力之下沒有中途放棄並成功完賽，對我來說真的不是一件容易的事情。因此，我也想要感謝我自己努力堅持了下來，才能擁抱如今的成長與經驗。

最後也要感謝那些鼓勵我的家人和朋友們，以及支持這個系列文的讀者們。自我價值的實現固然重要，然而讀者的回饋對於我來說也是非常重大的動力。再次感謝願意讀到這裡的你，希望這個系列文能夠對你有所幫助，那麼這些努力對我來說就都是值得的，期待與你在未來有機會再相見。